(1) Field of the Invention
This invention relates to a method for enhancing the retrieval of dynamic, web-based data, and more particularly to a methodology for generating quasi-static web page versions of dynamic web pages at predefined intervals.
(2) Description of the Related Art
With reference to FIG. 15, there is illustrated a typical web server architecture for assembling and delivering web content to a plurality of web browsers as known from the prior art. A plurality of web browsers 1511 are illustrated with each web browser 1511 in connectivity with network router 1515. As used herein, “connectivity” refers to the ability of two entities to exchange electronic information. Network router 1515 is in connectivity with web server component 1517. Web server component 1517 is comprised in part of web server 1519. Each web browser 1511 has access to cached data 1513. Cached data 1513 is data which is transient in nature and is stored in a format accessible to the device which has cached it. Cached data 1513 may reside in local memory, may be stored on a hard drive, or may exist in any format and on any medium capable of storing, retrieving, and sending cached data 1513 as requested by another device. Router 1515 is likewise in connectivity with cached data 1513. When a user requests information from a web server, the retrieved data may be stored for defined periods of time in several places as the requested data makes its way to the requesting web browser 1513.
These temporary storehouses of cached data 1513 serve to minimize the bottlencks which can form around operational databases in connectivity with web server 1519. For example, many users of web browsers 1511 may request within a short period of time the same web page from a web server 1519. It is not uncommon for the home page of a web site to be static in nature. As used herein, static data is data which does not change over relatively long periods of time. The length of such periods of time varies depending upon the precise nature of the data but is typically on the order of days, weeks, or longer. As users navigate throughout a web site, the choices which a user makes will likely necessitate the creation by the web server 1519 of web pages containing dynamic data. As used herein, dynamic data is data which changes over relatively short periods of time or which cannot be derived prior to a request for such data. The length of such periods of time varies depending upon the precise nature of the data but is typically on the order of minutes or hours. For example, after entering a web site, a user may request data pertaining to a plurality of products of interest. The web page which is assembled and sent to the web browser 1511 by the web server 1519 in response to such a request is formed of a particular set of product information which could not have been ascertained prior to receiving the user's request.
While requests for web pages containing dynamic data require interaction with the web server, many requests for web pages involve only static data and may therefore be cached for more effective delivery. Such caching is commonplace in the existing art. For example, a network router 1515 may store in its cached data 1513 every web page which it returns to a web browser 1511 as the result of routing the request to the web server 1519, receiving a response therefrom, and forwarding the response in the form of a web page back to web browser 1511. The length of time for which the network router's 1515 cached data 1513 is to remain resident in memory or otherwise accessible is a system parameter which may be set by the network administrator or other appropriate personnel or application. In this manner, subsequent requests of the network router 1515 by web browsers 1511 to retrieve a web page that has been cached by the network router 1515 may be satisfied by retrieving the web page not from the web server 1519 but from the network router's 1515 cached data 1513. In a similar manner, once a web page has been requested and received by a web browser 1511, the page will typically be stored by the web browser 1511 in cached data 1513 connected to the browser. Subsequent requests by the web browser 1511 for a web page that has been cached may result in the retrieval of the requested web page from cached data 1513 in connectivity with the web browser 1511 rather than being retrieved from the web server 1519.
In this manner, a typical network architecture can minimize the severity of web server 1519 bottlenecks. When a web browser 1511 requests a web page, the web browser 1511 checks to see if there is a copy resident in its cached data 1513. If there is, the cached web page is retrieved. If there is not a copy resident in the cached data 1513, the request is passed to the network router 1515. Similarly, the network router 1515 checks to see if it possesses a copy of the requested web page in its cached data 1513. If it does possess a copy, it retrieves the copy and passes it back to web browser 1511. If it does not possess a copy in cached data 1513, it passes the request on to web server 1519.
At each point in the network where caching takes place, it is possible to designate the period of time during which each copy of cached data 1513 is to remain valid. For example, a web browser 1511 may be configured to allow cached data to remain valid for a period of minutes, for the duration of the current session, or to remain valid in subsequent sessions. Network router 1515 may be configured to maintain cached data 1513 as valid for any desired period. In addition, at any time, a user may select the refresh option on web browser 1511 and force an update from web server 1519 rather from any cached data 1513 version located anywhere throughout the network.
With reference to FIG. 16 there is illustrated a more detailed representation of a typical web server component 1517′ as known from the prior art. Web server component 1517′ includes an additional methodology by which web pages may be assembled for delivery by a web server 1519. As illustrated, web server component 1517′ is additionally comprised of connection 1627, executable 1621, executable repository 1623, and operational database 1625. Connection 1627 comprises the interface which provides connectivity between web server 1519 and network router 1515. Executable 1621 is a self contained application that, when invoked by web server 1519, assembles a web page and sends it to the requesting web browser 1511 via connection 1627. Executable 1621 has access to executable repository 1623 which serves as a memory device in which executable 1621 can store the results of its execution. Operational database 1625 maintains the run-time data of the network architecture. This data may be stored in, but is not limited to, a relational database.
Instead of requesting a web page, a web browser 1511 may instead request the invocation of executable 1621. Executable 1621, when invoked, executes to assemble a web page which matches the request and returns the web page to web browser 1511 via router 1515. One common language in which executable 1621 is written is Active Server Pages or ASP. ASP is an interpreted language which contains static text, such as HTML, as well as ASP commands. Typical ASP commands are delimited by character sequences such as “<%” and “%>”. When invoked, the ASP code outputs the static HTML code “as is” to executable repository 1623 while performing the execution of commands written in ASP and appending the results to executable repository 1623. In this manner, an HTML page may be coded in ASP which contains static elements as well as elements which are filled at run time by performing data base accesses from operational database 1625 and the like. While drawn to an ASP implementation, executable 1621 may be written in any language which returns to the requestor information formatted in an appropriate manner.
The present state of the art requires that a web page be either static or dynamic in nature. As a result, a page coded in ASP, dynamic in nature, will often require the invocation of executable 1621 and the attendant access to operational database 1625 in order to fulfill a request for the web page generated by executable 1621. Such database access can result in redundant requests of an operational database the result of which may be slower system response times. However, data which is dynamic is in fact often static over a well defined period of time. For example, product price information may be updated in operational database 1625 on the last day of each month. If a web browser 1511 requests a web page illustrating products and their prices, web browser 1511 would typically invoke ASP code rather than requesting a static web page. This results from the fact that product prices change from time to time. Were the prices unchanging, a static HTML page could be created and stored to be sent to web browsers 1511 in the event of a request for such information. Therefore, any web page which contains dynamic data must be coded in ASP, or a similar language, and will always invoke a retrieval from the operational database 1625.
However, because the dynamic data which records product prices changes quite infrequently, being updated only once a month, it would be desirable to devise a method whereby infrequently changing dynamic data could be handled like static HTML data and stored for immediate retrieval without the necessity of an operational database 1625 query. There is therefore a need in the art to devise a method whereby infrequently changing data contained within a web page can be generated as a static page, in a format such as HTML, rather than as a web page dynamically created by the execution of ASP or other code. Such a methodology would serve to reduce the bottlenecks formed when data is requested which requires interaction with the operational database 1625.
In contrast to existing methodologies whereby ASP or other code is invoked to dynamically create a web page in response to a request, there is needed a methodology whereby the same page, or substantially the same page, could be requested as a static web page thus avoiding unnecessary queries to an operational database. Such a methodology would constitute a substantive change in the manner by which existing methodologies seek to create and return dynamic data in response to user requests.